The present invention is related to data-flow-based computer simulation of systems. In particular, the present invention is related to modules for accommodating interaction phenomena associated with simulation.
Robotic, or more inclusively, intelligent machine (IM) system technologies are growing in capability and the degree and scope with which they can be integrated. Whereas factories once used robots in cells of integration, modern factories have begun to exhibit characteristics of integrated, distributed, multi-user IM systems. Likewise, new military concepts are emphasizing network-centric warfare with distributed sensing, computer-assisted decision-making and automated response over earlier concepts using discrete independently controlled robots. New military systems will also behave like integrated, distributed, multi-user IM systems. The world is moving from systems using robots to systems which, while using robots, are themselves robotic. At the same time, rapidly accelerating computer capabilities make computationally intensive user interfaces with 3D simulation environments proliferate.
An advantage of data-flow-based modular simulation is that a data-flow network can structurally model the complex system being simulated, while individual modules can easily be replaced or modified as needed to change simulation fidelity, incorporate improved simulation models, reflect component modifications, and the like. All the usual advantages of modular software—code-reusability, robustness, maintainability, also apply.
In conventional data-flow-based modular simulation, e.g., LabView, Simulink, and the like, each individual module simulates a component of the larger system. Simulation of this kind can be considered a form of what has become known in the art as port-based simulation. In a data-flow-based modular simulation, each module is an automaton taking data at its input ports, performing some type of computation involving the data, and providing the data, which can be transformed according to a suitable transfer function, at its output ports, usually once per simulation cycle. In a clean implementation, computation or transformation is performed by what is referred to as the module's update function. In accordance with a typical C++ implementation, modules are instances of classes and can retain their state between simulation cycles. Data flows through connections from one module's output port to another module's input port, with each connection carrying information created by the sender to be used by recipients. If the data flow graph representing the data flow among a network of modules contains cycles, then a minimal set of connections can be established such that the original graph minus the set of connections is acyclic. The set of connections can be designated, for example, as feedback connections in the simulation description. It should be noted that the feedback connections are not considered when determining update order. Thus, the order in which modules' update functions are called during a simulation cycle is determined by the data flow graph minus feedback connections, and the data at the output port of a feedback connection is readable at the corresponding input port during the following simulation cycle.
Such a basic approach is useful for simulating a system whose components have static interaction relationships. For example, a network of modules might be used to simulate a robotic manipulator. If, however, two entities to be simulated do interact, a simple approach to simulating the resulting coupled system involves modifying connections of interacting modules. It should be noted that in a conventional data-flow-based and port-based modular simulation system, all data movement between modules occurs through data-flow connections. Accordingly, in order to simulate two interacting entities associated with such a system, either data-flow connections should be established from modules simulating one entity to modules simulating the other, and possibly vice-versa, or a chain of alternating data-flow connections can be established between modules simulating one entity to modules simulating the other, perhaps forming something resembling a switching network.
A problem arises however, in that interaction phenomena can involve a large and/or undetermined number of devices or components. Since, in general, in data-flow-based modular simulation, e.g., LabView, Simulink, and the like, the types and number of input and output ports of a given module class are static, conventional approaches to dealing with interaction phenomena associated with interfacing with large undetermined numbers of devices might include each simulated module to have inputs connected to the outputs of the corresponding modules with a quadratic number of connections. If a switching module is used to connect inputs to outputs, the quadratic number of connections can be replaced with a linear number of connections. Assuming that modules behave properly when not all inputs are connected, such an approach might be sufficient when fewer than the original number of entities are involved. However, if it becomes necessary to simulate a scenario containing more than the original number of entities, the module code would require modification, leading to a multiplicity of module classes which would be identical except for the numbers of input and output ports.
It would be desirable therefore in the art for a method and apparatus for extending data-flow-based simulation with modules for accommodating interaction phenomena. Such a method and apparatus would allow large and/or undefined numbers of connections to be accommodated without modifying simulation module classes.